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1  Introduction 


Background 

Historically,  controls  for  utility  systems  have  undergone  dramatic  change.  Heating, 
Ventilating,  and  Air-Conditioning  (HVAC)  systems,  for  example,  were  first 
controlled  manually,  then  mechanically,  then  pneumatically,  then  with  electronic 
analog  devices,  and  finally  by  microprocessor  control.  While  microprocessor  control 
provides  many  benefits  over  previous  methods,  it  also  raises  new  questions  and 
challenges  for  designers  and  users.  While  the  means  of  control  has  changed,  the 
companies  that  share  the  majority  of  the  Army  utility  controls  market  have  not  yet 
changed.  The  use  of  more  general  purpose  control — Direct  Digital  Control — 
hardware  such  as  personal  computers  and  data  acquisition  cards,  industrial-based 
PC  systems  such  as  those  based  on  the  STD  and  VME  bus,*  programmable  logic 
controllers  (PLCs),  and  even  single  loop  digital  controllers  (SLDCs)  have  greatly 
affected  industrial  controls  and,  to  a  lesser  degree,  utility  controls  such  as  those 
found  in  HVAC.  SLDCs  have  become  the  standard  controls  requirement  for  Army 
HVAC  control  in  new  construction. 

For  example,  the  PLC,  which  was  once  used  almost  exclusively  in  the  process  and 
manufacturing  industries,  has  recently  become  a  much  more  versatile  controller 
and  consequently  has  acquired  the  interest  of  other  control  markets.  Software  for 
these  alternative  controls  has  improved  dramatically  in  capabilities  and  ease  of  use. 
Many  third-party  software  vendors  have  interfaced  their  products  with  these 
industrial  control  devices.  Drivers  that  allow  monitoring,  programming,  and 
supervisory  control  via  a  central  PC  can  interface  to  several  different  vendors  (one 
interfaces  with  over  150  different  devices)  make  multiple-vendor  control  system  a 
real  possibility. 

In  the  past,  these  industrial  control  hardware  have  offered  little  competition  to 
commercial  controls  largely  because  of  their  relatively  higher  cost  and  more  limited 
functionality.  PLCs,  for  instance,  began  as  relay  replacements  and  had  only  digital 
input-output  (I/O).  The  control  industry  has  seen  a  great  many  changes  in  the  last 


STD  bus  is  defined  by  IEEE  Standard  961 , 1987  (R1994)  (Institute  of  Electrical  and  Electronics  Engineers,  P.O. 
Box  1331 ,  Piscataway,  NJ  08855-1 331 );  VME  bus  is  defined  by  the  VMEbus  Trade  Association,  1 0229  N. 
Scottsdale  Road,  Suite  B,  Scottsdale.  AZ  85253-1437,  tel.  602/951-8866. 
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5  years.  PLCs  are  no  longer  large,  expensive,  strictly  digital  devices  for  use 
exclusively  in  manufacturing  and  batch  control  environments.  They  now  come  in 
a  variety  of  packaging  arrangements,  have  analog  I/O,  include  advanced  mathemat¬ 
ical  capabilities  (e.g.,  proportional-integral-derivative  [PID]  function,  square  root 
calculation,  multiplication,  division),  and  have  user-friendly  graphical  programming 
interfaces. 

While  some  of  the  inherent  problems  of  microprocessor  control  remain,  their 
domination  of  the  large  manufacturing  industry  has  resulted  in  refined  capabilities 
so  they  now  offer  an  attractive  alternative  in  environments  requiring  both  digital 
and  analog  I/O.  Industrial  and  commercial  controls  are  becoming  increasingly 
similar.  Industrial  controls  such  as  PLCs  also  appear  to  have  a  decided  advantage 
in  the  area  currently  receiving  a  great  deal  of  interest:  multiple-vendor  control 
systems.  This  review  of  control  system  hardware  and  software  alternatives  was 
undertaken  to  evaluate  direct  digital  controls  for  their  potential  applicability  to 
utility  systems  on  U.S.  Army  installations. 


Objectives 

The  objectives  of  this  research  were  to  identify  and  evaluate  the  various  micro¬ 
processor-based  control  (direct  digital  control)  hardware  and  software  available  for 
use  as  utility  controls  at  U.S.  Army  installations. 


Approach 

1.  Literature  searches  on  various  control  systems  was  performed. 

2.  Manufacturers  of  various  control  systems  were  contacted  via  phone,  trade 
shows,  and  mail  for  information  on  their  system. 

3.  Various  hardware  and  software  was  purchased  and  evaluated. 

4.  Results  of  the  evaluation  were  compiled  and  conclusions  were  developed. 

Notice 

This  study  reviewed  products  manufactured  and/or  marketed  by  a  number  of  firms. 
Mention  of  companies  or  products  listed  below  does  not  constitute  an  endorsement 
of  products  or  manufacturer,  and  use  of  information  contained  in  this  report  for 
advertising  without  obtaining  clearance  according  to  existing  contractual  agree¬ 
ments  is  prohibited. 
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Allen  Bradley: 

1201  South  Second  Street 

Milwaukee,  Wl 53204 

414/382-2000 

American  Automatrix: 

One  Technology  Drive 

Export,  PA  15632 

412/733-2000 

Andover  Controls: 

300  Brickstone  Square 

Andover,  MA  01810 

617/470-0555 

Barber  Coleman: 

Now  owned  by  Siebe 

Cornell  University: 

Ithaca,  NY  14853 

607/255-4824 

GESPAC: 

50  W.  Hoover 

Mesa,  AZ  85210 

602/962-5559 

Honeywell: 

621  R.  83 

Bensenville,  IL  60106 

708/860-3869 

ISA: 

67  Alexander  Drive 

PO  Box  12277 

Triangle  Research  Park,  NC  27709 

919/549-8288 

Johnson  Controls: 

2188  Welsch  Industrial  Court 

St.  Louis,  MO  63146-4291 
(314)  569-1570 

Landis  and  Gyr  Powers: 

1 000  Deerfield  Parkway 

Buffalo  Grove,  IL  60089 

708/215-1050 

Modicon: 

;  AEG  Schneider  Automation,  In. 

One  High  Street 

North  Andover,  MA  01845 

508/794-0800 

NIST: 

Gaithersburg,  MD  20899 

301/975-5873 

Public  Works  Canada 

Sir  Charles  Tupper  Building 

Riverside  Drive 

Ottawa,  Ontario  K1 A  OM2 

613/736-2257 

Robertshaw  Controls: 

Now  owned  by  Siebe 

Siemens 

1600  Route  22 

Union,  NJ  07083 

908/687-7672 

Staefa  Control  Systems: 

8515  Miralani  Dr. 

San  Diego,  CA  92126 

619/530-1000 

Trane: 

3600-T  Pammel  Creek  Rd. 

LaCrosse,  Wl  546001 

608/787-2000 

Transys: 

5010  East  Shea  Blvd.  Suite  C-226 

Scottsdale,  AZ  85254 

602/483-7924 

Universal  Software: 

No  longer  in  business 

Scope 

Hardware  price  estimates  quoted  in  this  report  reflect  actual  purchases  or  manufac¬ 
turer  estimates  made  during  this  study. 


Mode  of  Technology  Transfer 

It  is  anticipated  that  the  information  gained  in  this  study  will  be  incorporated  into 
future  work  to  incorporate  DDC  controls  into  Army  utility  systems,  as  DDC  tech¬ 
nology  becomes  available  in  a  nonproprietary,  cost-effective  manner. 
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2  Digital  Control 

Direct  Digital  Control  and  EMCS 

A  digital  device  is  one  that  operates  on  binary  (two)  values.  “Digital  control”  refers 
to  either  supervisory  or  direct  control  of  one  or  more  devices  through  a  controller 
that  is  based  on  a  digital  device  (such  as  a  microprocessor)  by  an  Analog  to  Digital 
(A/D)  converter.  While  the  resolution  of  A/D  converters  is  not  of  great  concern  in 
HVAC  applications,  a  discussion  of  it  is  pertinent  for  understanding  specifications. 
Note  that  resolutions  to  hundredths  or  tenths  of  degrees  are  usually  not  meaningful 
in  HVAC  applications.  Direct  Digital  Control  (DDC)  is  the  direct  control  of  a  device 
by  a  digital  controller.  In  Figure  1,  for  example,  the  signal  that  modulates  the  valve 
comes  directly  from  the  digital  controller.  This  differs  from  an  Energy  Monitoring 
and  Control  System  (EMCS)  (Figure  2),  in  which  the  digital  controller  monitors  a 
temperature,  but  its  single  output  varies  the  setpoint  of  the  pneumatic  controller. 
The  signal  modulating  the  valve  comes  from  the  pneumatic  controller.  Two  major 
differences  distinguish  EMCS  from  DDC  systems: 

1.  In  an  EMCS  system,  the  local  loop  is  controlled  by  a  device  that  is  separate 
and  independent  of  the  EMCS  system.  The  most  typical  form  of  the  local 
controls  is  pneumatic,  but  local  controls  could  also  be  electronic  or  mechanical. 


Figure  1.  Direct  digital  control. 
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Figure  2.  Local  pneumatic  controls  with  ECMS  setpoint. 


2.  EMCS  systems  require  duplicate  sensors. 

When  EMCS  systems  were  first  installed,  the  price  of  computing  hardware  was 
much  higher  than  it  is  today.  An  economical  EMCS  system  was  generally 
comprised  of  one  large  computer  that  performed  all  of  the  computing.  For  the  sake 
of  reliability,  this  computer  performed  only  supervisory  control.  The  local  loop  was 
always  controlled  directly  by  local  controls.  As  hardware  costs  decreased,  it  became 
economically  feasible  to  distribute  computing  hardware  to  the  field,  resulting  in 
systems  like  the  one  shown  in  Figure  2.  Digital  controls  have  rapidly  become 
“intelligent”  tools.  The  typical  distributed  DDC  system  today  consists  of  intelligent 
field  panels  with  a  personal  computer  acting  as  the  central  console  user  interface 
to  monitor  and  collect  data.  Future  technologies  are  likely  to  continue  the  trend  by 
even  further  distributing  “intelligent”  hardware  all  the  way  down  to  the  sensor 
level.  This  has  already  happened  in  many  process  industries. 


Analog  Input 

Variables  such  as  temperature,  pressure,  humid¬ 
ity,  and  flow  are  monitored  by  DDC  controllers  via 
an  analog  input  (AI)  module.  An  AI  signal  usually 
arrives  at  the  DDC  controller  as  a  continuously 
variable  voltage  or  current.  Table  1  shows  typical 
input  ranges  for  AI  modules. 


Table  1.  Typical  analog  input  ratings. 
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Temperatures,  for  instance,  are  typically  measured  by  monitoring  a  voltage  or 
current  that  varies  with  the  resistive  property  change  of  the  sensor.  The  voltage  or 
current  signal  is  then  transduced  by  an  Analog  to  Digital  (A/D)  converter.  The  A/D 
converts  the  voltage  or  current  level  into  an  input  signal  the  computer  can 
understand,  normally  a  digital  word  that  can  be  characterized  by  its  size.  Typical 
sizes  are  8, 12,  or  16  bits.  The  8-bit  digital  word  has  256  (28)  discrete  increments. 
This  size,  referred  to  as  the  resolution,  affects  the  control  system’s  accuracy.  For 
example,  a  sensor  rated  from  zero  to  100  °F  might  have  a  transducer/transmitter 
that  outputs  4  to  20ma,  and  that  is  read  by  a  circuit  with  an  A/D  converter  designed 
for  this  input  range.  Temperature  measurements  in  this  example  are  transduced 
into  256  discrete  values,  or  0.39  °F  increments.  This  means  that  a  microprocessor- 
based  controller  would  have  to  interpret  the  temperature  between  the  0.39  °F 
increment  to  the  nearest  rounded  off  value.  A  temperature  of  0.10  °F,  for  instance, 
is  interpreted  as  0  °F: 


Resolution  =  100°F/256  =  0.39  °F 


[EqlJ 


Increasing  the  bit  size  of  the  A/D  converter  increases 
the  number  of  discrete  values  that  represent  the 
measured  temperature.  A  12-bit  converter,  for  exam¬ 
ple,  has  4096  (212)  discrete  values.  A  16-bit  converter 
has  a  resolution  of  65536  (216)  incremental  steps. 
Table  2  lists  the  various  resolutions  for  a  0  to  100  °F 
sensor,  transmitter. 


Table  2.  Resolutions  for  0-100  °F 


sensor,  transmitter. 


D/A  Bits 

Resolution 

8 

0.391  °F 

12 

0.024  °F 

16 

0.001  °F 

Analog  Output 

The  AO  signal  is  generated  by  reversing  the  process  for  an  AI.  It  begins  as  a  digital 
word,  or  value,  computed  by  the  microprocessor,  which  is  sent  to  a  Digital  to  Analog 
(D/A)  converter.  At  the  D/A  converter,  the  digital  value  is  converted  to  a  voltage  or 
current;  this  signal  is  eventually  sent  to  an  actuator  device.  Pneumatic  actuators 
are  by  far  the  most  common  in  HVAC,  so  in  this  case,  the  voltage  or  current  signal 
is  converted  to  a  pneumatic  signal  via  either  an  E/P  (voltage  to  pneumatic)  or  I/P 
converter  (current  to  pneumatic)  transducer. 
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Digital  Input 

A  digital  input  (DI)  (i.e..  Binary  Input)  signal  usually  originates  at  a  switch  or  relay 
of  some  kind.  This  signal  has  only  two  defined  states,  either  on  or  off,  open  or 
closed.  Since  a  bit  also  has  two  values,  the  controller  needs  only  one  bit  to  detect 
the  state  of  a  DI.  This  means  that  a  DI  status  can  be  evaluated  by  the  microproces¬ 
sor  by  evaluating  single  bits.  Analog  input,  on  the  other  hand,  requires  evaluation 
of  several  bits,  the  number  of  which  depends  on  the  resolution.  Digital  inputs  are 
rated  in  terms  of  voltage  ranges,  current  ranges,  and  type  of  current  (alternating 
or  direct  current). 

The  two  states  are  specified  in  terms  of  minimum  and  maximum  values.  Typically, 
one  state  is  defined  as  off  and  the  other  as  on.  The  off  state  is  defined  by  some 
maximum  voltage  at  which  the  input  is  no  longer  considered  to  be  off.  The  on  state 
is  defined  by  a  minimum  voltage  below  which  the  input  is  no  longer  considered  to 
be  on.  Voltages  in  between  these  minimum  and  maximum  values  have  no  defined 
state.  In  Figure  3,  the  off  state  is  defined  as  an  input  value  between  zero  and  0.4V 
and  the  on  state  is  defined  as  4.6  to  5.0V.  Any  other  value  is  undefined.  While  the 
off  state  is  usually  defined  as  a  value  near  zero  volts  as  in  our  example,  the  on  state 
varies  according  to  the  field  device  being  monitored.  Table  3  lists  typical  values  for 
the  on  state  (Bryan  and  Bryan  1988). 


Voltaqe 


Figure  3.  Digital  input. 
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Most  of  these  ranges  are  self  explanatory,  with  the  possible 
exception  of  “TTL”  and  “Non-Voltage.”  TTL  (Transistor- 
Transistor  Logic)  Level  inputs  have  input  circuitry  similar  to 
the  AC/DC  inputs,  but  the  input  delay  time  caused  by  filtering 
is  generally  much  shorter,  making  them  suitable  for  applica¬ 
tions  requiring  fast  processing.  The  field  device  connected  to 
the  TTL  DI  module  must  of  course  be  capable  of  generating  a 
TTL  (5VDC)  signal.  A  non-voltage  input  is  one  in  which  the 
field  device  is  not  required  to  be  powered  by  an  external  power 
source.  Typical  non-voltage  field  devices  include  dry  contacts 
from  standard  relays,  some  proximity  or  photoelectric  switches, 
and  solid  state  relay  or  instrumentation  devices  that  provide 
an  open  collector  output. 


Table  3.  Typical  digital 
input  ratings. _ 

24  Volts  AC/DC 


48  Volts  AC/DC 


120  Volts  AC/DC 


230  Volts  AC/DC 


TTL  Level 


Non-Voltage 
Isolated  Input 
5-50  Volts  DC 


Digital  Output 

A  digital  output  (DO)  (i.e.,  a  Binary  Output),  much  like  the  DI,  also  has  two  possible 
states  and  is  represented  in  the  controller  by  a  single  bit.  A  DO  is  used  to  turn 
equipment  on  and  off,  such  as  motors,  pilot  lights,  and  alarms.  Usually  intermedi¬ 
ate  relays  are  required  between  the  DO  of  the  controller  and  the  intended  device 
due  to  voltage  and  current  limitations  of  the  digital  controller  DO.  Output  ratings 
for  DO  are  similar  to  those  for  DI  (Table  3). 


New  Challenges 

In  the  past,  the  EMCS  operated  completely  independent  of  the  local  controls  with 
the  exception  of  setpoint  reset,  so  it  was  not  a  problem  if  the  local  controls  in  one 
building  were  made  by  a  different  manufacturer  than  those  in  another  building.  If, 
however,  it  is  desired  to  interconnect  direct  digitally  controlled  loops  into  a  distrib¬ 
uted  system  to  perform  energy  management  functions,  central  monitoring,  etc.,  then 
suddenly  several  problems  arise.  Proprietary  communications  performing  global 
functions  such  as  demand  limiting  will  become  difficult  through  the  EMCS. 


Various  Control  Hardware  Choices 

Several  types  of  controls  are  available  today,  each  with  specialized  features  that 
make  it  unique.  Controls  can  be  broadly  categorized  into  two  types:  commercial 
and  industrial.  Commercial  systems  tend  to  be  more  “general  purpose”  in  nature, 
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and  industrial  controls  tend  to  be  more 
specialized.  Industrial  controls  also 
tend  to  be  designed  to  function  in  rela¬ 
tively  harsh  environments.  Another 
useful  distinction  is  between  single- 
and  multi-loop  controllers.  The  differ¬ 
ence  between  single-  and  multi-loop 
DDCs  is  the  way  that  the  hardware  is 
packaged.  Single-loop  refers  to  hard¬ 
ware  packaged  so  each  loop  is  con¬ 
trolled  by  a  separate  piece  of  hardware 
(Figure  4).  Multi-loop  refers  to  hard¬ 
ware  packaged  so  multiple  loops  are 
controlled  by  a  single  piece  of  hardware 
(Figure  5). 


Analog  Out 


Loop  #1 

—  Analog  In 

Single  Loop 

Digital  Controller 

Digital  Out  ^ 

—  Digital  In 

Loop  #2 —  Ana  log  Out 


^  Analog  In 

Single  Loop 

Digital  Controller 

Digital  Out 

—  Digital  In 

Figure  4.  Single-loop  digital  controller. 


While  this  study  attempted  to  review 
controls  with  a  general  application  to 
all  utilities,  HVAC  systems  were  em¬ 
phasized  because  HVAC  systems  are 
common,  and  because  HVAC  systems 
have  traditionally  been  controlled  with 
digitally  based  hardware  designed  spe¬ 
cifically  for  that  segment  of  the  control 
industry.  In  fact,  the  term  DDC  has 
been  incorrectly  used  in  the  HVAC 
industry  to  refer  exclusively  to  this 
hardware,  which  is  referred  to  in  this 
report  as  “commercial  DDC.” 


Loops  #1  and  #2 


^  Analog  In  #1 _ 

Analog  Out 
^  Digital  In  #1 
Digital  Out 
^  Analog  In  #2 
Analog  Out 
^  Digital  In  #2 
Digital  Out 


Figure  5.  Multiple-loop  digital  controller. 
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3  Programmable  Logic  Controller 


Background 

Modicon  introduced  the  first  programmable  logic  controller  (PLC)  in  1969  as  a 
replacement  for  the  massive,  hard-wired  relay  panels  used  in  manufacturing  plants 
to  control  machine  tools  and  assembly  lines.  The  novel  feature  of  this  new  device 
was  that  it  was  programmable.  The  PLC  not  only  saved  factory  floor  space  by 
replacing  the  relay-based  systems,  but  it  could  also  be  reprogrammed  for  different 
applications.  This  was  quite  an  improvement  over  hard-wired  systems,  which  often 
had  to  be  scrapped  for  even  the  slightest  change  to  the  manufacturing  scheme 
because  it  was  more  expensive  to  redesign  and  rewire  than  to  start  from  scratch. 
PLCs  are  famous  for  their  ability  to  withstand  severe  environments  and  for  their 
long-term  reliability.  The  additional  features  of  modularity,  expendability,  diagnos¬ 
tics,  and  reliability  in  an  industrial  environment  also  led  to  the  PLCs  success. 

Since  1969,  PLCs  have  evolved  from  strictly  logic-oriented  devices  into  extremely 
sophisticated  microprocessor-based  devices  with  increased  capabilities.  They  have 
recently  become  available  in  a  variety  of  packages  with  the  necessary  capabilities 
such  as  analog  I/O  to  make  them  an  economical  alternative  to  “traditional  DDC.” 
PLCs  continue  to  enjoy  a  reputation  as  a  reliable  source  for  manufacturing  and 
process  control,  and  their  use  can  be  expected  to  expand  into  other  industries  such 
as  HVAC.  PLCs  are  versatile  devices  that  deserve  consideration  as  the  solution  to 
many  control  requirements,  not  just  relay  replacements.  One  example  of  this  is 
their  use  in  many  manufacturing  facilities  as  the  HVAC  controls  (Cole  and  Holness 
1989).  This  seems  to  be  the  norm  in  facilities  that  use  PLCs  for  processes  such  as 
manufacturing.  There  is  at  least  one  known  case  where  a  “commercial  DDC”  vendor 
subcontracted  to  an  architectural-engineering  firm  to  install  PLCs  for  the  HVAC 
controls  in  lieu  of  the  controls  manufactured  by  the  contractor.* 

Despite  the  versatility  of  today’s  PLCs,  many  controls  professionals  hesitate  to 
apply  PLCs  to  new  applications  such  as  HVAC  controls.  In  the  past,  legitimate 
reasons  prevented  the  use  of  PLC  technology  for  facility  control  processes.  Some  of 
these  included  a  lack  of  knowledge  of  these  systems  by  people  within  the  facility 


Phone  conversation  with  James  Frakes,  Frakes  Engineering,  Indianapolis,  IN  46250  (June  1992). 
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controls  industry,  the  requirement  for  programming,  a  lack  of  capability  of  the 
technology,  and  the  high  purchase  cost.  Many  of  these  characteristics  have  changed 
significantly  in  recent  years.  PLCs  have  been  standardized.  Originally,  these 
systems  were  characterized  as  “relay  replacers”  because  their  initial  function  was 
to  eliminate  the  need  for  hard-wired  control  relay  panels.  They  proved  very  useful 
in  industry  for  their  ability  to  implement  quick  and  easy  changes  in  system  control 
logic  via  software  changes,  thereby  eliminating  the  need  for  making  hard-wire 
changes  in  physical  control  panels.  The  maturing  technology  gained  the  ability  to 
perform  PID  control,  communicate  from  peer-to-peer,  and  communicate  with  host 
computers  over  common  networks  topologies.  Many  PLCs  can  now  be  programmed 
via  a  personal  computer  (PC)  in  common  languages,  e.g.,  BASIC,  C,  etc.,  in  addition 
to  graphical  methods. 


Hardware 

A  PLC  control  system  is  typically  built  from  a  backplane  and  several  modules 
including  a  CPU,  AI,  AO,  DI,  DO,  and,  in  some  cases,  a  separate  power  supply  and 
memory  modules.  Figure  6  shows  a  typical  backplane  that  mounts  on  a  standard 
DIN  rail.  Modules  insert  into  this  backplate  (Figure  7),  which  contains  the  media 
(addressing  and  data  busses)  for  communications  between  the  various  modules. 
Some  vendors  offer  backplanes  with  the  power  supply  and  or  CPU  integrated  into 
one  assembly,  but  this  is  not  extremely  popular  since  it  decreases  serviceability. 
Once  the  modules  are  in  place,  wire  terminations  from  I/O  can  be  made  at  the 
detachable  screw  terminals  (Figure  8).  Their  modular  approach  for  assembling  a 
control  system  to  meet  the  requirements  of  the  application  at  hand  is  one  of  their 
great  assets.  The  availability  of  a  wide  range  of  I/O,  CPU,  and  specialty  modules 
contributes  to  the  PLC’s  ease  of  maintenance,  reusability,  and  expendability. 
Table  4  shows  the  wide  variety  of  I/O  modules  available  for  several  typical  PLCs. 

These  product  lines  would  fit  well  in  HVAC  applications  because  of  their  ability  to 
provide  low  I/O  counts  at  reasonable  costs  while  maintaining  functional  require¬ 
ments  such  as  built-in  PID  algorithms.  Most  vendors  also  produce  fixed  I/O  PLCs, 
which  are  similar  to  the  commercial  DDC  hardware  typically  referred  to  as 
“Application  Specific  Controllers”  (ASC).  These  usually  provide  low  I/O  point 
counts,  and  some  contain  no  analog  I/O  (i.e.,  they  contain  digital  I/O  only).  A  typical 
AI  module  can  usually  be  configured  for  either  a  voltage  or  current  input.  A  large 
number  of  ranges  are  available;  zero  to  10V  and  4  to  20mA  are  typical  ranges. 
Modules  with  a  wide  range  of  the  number  of  inputs  are  available,  with  two  to  eight 
inputs  per  module  being  typical  of  smaller  PLCs  that  would  likely  be  used  for  utility 
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Figure  6.  PLC  backplate. 
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Table  4.  PLC  I/O  capacities  per  module. 


PLC  Manufacturer 

Digital  Input 

Digital  Output 

Analog  Input 

Analog  Output 

GE  90-30  Series 

16 

16,  12,  8,5 

4 

2 

GE  90-70  Series 

32,  16,  12 

32,  16, 12,8 

8,4 

4,2 

Allen  Bradley  SLC-500  Series 

32,  16,  8,4 

32,  16,  12,  8,4 

4,  2 

4,2 

Siemens/TI  405  Series 

16,  8,4 

16,  12,8,4 

8,4 

8,4 

Modicon  984-120  Compact  PLC 

16,8 

16,8,4 

4 

8,2 

B&R  Industrial  M264  Series 

24,  16,  8 

24,  16,  12,  8 

16,  8,4 

8,4 

controls.  If  more  inputs  are  required  than  available  in  a  single  card,  multiple 
modules  are  added  to  the  rack. 

The  analog  signal  originates  at  the  sensing  element,  after  which  it  comes  into  the 
module  and  is  fed  into  an  A/D  converter.  The  corresponding  digital  word  of  this 
signal  is  used  by  the  microprocessor  in  calculating  the  output  control  signals.  As 
previously  discussed,  the  description  of  the  number  of  bits  used  and  resolution  also 
applies  to  the  AI  module  of  the  PLC. 

AO  modules  are  very  similar  to  AI  modules,  but  typically  are  available  with  lower 
point  counts  because  of  the  tendency  to  have  more  AI  than  AO.  Combination 
modules  with,  for  example,  four  AI  and  two  AO  are  popular  because  of  this.  Again, 
for  reasons  previously  discussed,  AO  signals  for  PLCs  can  typically  be  configured 
for  either  zero  to  10V,  4  to  20mA,  or  zero  to  20mA. 

CPU  modules  differ  mainly  in  processor  speed,  bus  capability  (number  of  data  and 
address  bits),  and  amount  of  memory.  Both  analog  and  digital  I/O  modules  can  then 
be  added  to  meet  the  application  requirements.  Because  the  CPU  module  used 
determines  the  nonnetworked  I/O  capacity,  a  large  variety  of  modules  is  typically 
available.  For  example,  the  minimal  configuration  of  the  PLC  that  was  used  to 
build  a  panel  to  control  a  VAV  air  handler  with  both  analog  and  digital  I/O  would 
consist  of  one  CPU  module  (Modicon  984-A120)  and  one  each  of  the  I/O  types  for  a 
total  of  five  modules  resulting  in  eight  digital  inputs,  four  digital  outputs,  four 
analog  inputs,  and  two  analog  outputs.  This  hardware  lists  at  $1,500. 

I/O  capacity  in  PLCs,  which  is  a  function  of  the  CPU  module,  is  usually  specified  in 
terms  of  bits.  An  area  of  memory  accessible  by  the  CPU  called  the  Data  Table 
determines  I/O  capacity.  The  Data  Table  is  sometimes  divided  into  two  separate 
tables,  one  for  inputs  and  the  other  for  outputs,  called  the  Input  Table  and  Output 
Table  respectively.  Digital  I/O  takes  one  bit  per  point  and  analog  I/O  takes  a 
number  of  bits  equal  to  its  resolution.  An  AI  module  with  four  channels  and  12-bit 
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resolution  would  require  48  bits  of  Data  Table  memory.  The  Modicon  984-A120 
CPU  module,  for  example,  has  a  512-bit  Data  Table.  The  resolution  of  its  analog 
I/O  is  16  bits.  This  particular  CPU  module  is  also  constrained  to  a  maximum  of  256 
digital  I/O.  One  possible  configuration  is  therefore  24  analog  I/O  (taking  up  384 
bits)  and  128  digital  I/O  (taking  up  128  bits)  for  a  total  of  512  bits. 

To  further  expand  the  total  networked  point  count,  247  of  these  CPU  modules  can 
be  networked  together  via  the  built-in  master-slave  communications  port.  If  this 
does  not  meet  the  application  requirements,  other  CPU  modules  are  available  in  the 
same  product  line  (18  total)  which  have  different  capacities  and  speeds,  all  of  which 
are  both  hardware  and  software  compatible.  This  is  evidenced  by  the  following 
statement:  “The  984  instruction  set  (the  functional  capabilities  of  the  controller, 
part  of  the  system  firmware  stored  in  executive  PROM)  comprises  logic  functions 
common  to  other  984s.  This  means  that  user  logic  created  on  a  mid-range  or  high- 
performance  unit  such  as  a  984-685  or  a  984B  can  be  relocated  to  a  smaller 
controller  such  as  a  984-145  (assuming  sufficient  memory  in  the  smaller  machine) 
and  that  logic  created  on  a  smaller  controller  is  upwardly  compatible  to  a  larger 
unit.  As  your  application  requirements  increase,  it  is  relatively  easy  to  upgrade 
your  controller  hardware  without  having  to  rewrite  control  logic”  (Modicon  1991). 

PLC  hardware  is  extremely  rugged  and  reliable,  as  evidenced  by  the  data  listed  in 
Table  5,  which  shows  the  mean  time  between  failure  (MTBF)  values  of  various  PLC 
components  for  two  PLC  vendors.  The  MTBF  was  calculated  for  the  components  of 
the  PLC  hardware  combined  to  function  as  a  single  unit.  The  VAV  air  handling 
unit  as  specified  in  the  Army  Corps  of  Engineers  Technical  Manual  on  HVAC  con¬ 
trols  (Technical  Manual  [TM]  5-815-3)  was  chosen  as  a  typical  control  panel  and  the 
MTBF  of  a  PLC  panel  for  this  configuration  was  calculated  as  specified  in  the  Corps 
of  Engineers  “EMCS  Overall  Reliability  Calculations”  (U.S.  Army  Corps  of  Engi¬ 
neers  Huntsville  Division  1987).  The  I/O  points  required  for  this  panel  are  given 


Table  5.  PLC  MTBF. 


Module 

MTBF  (Hours) 

Modicon  984-A120 

Siemens  Tl  405 

CPU 

400,000 

1,812,000 

Digital  Input  Module 

1,029,866 

568,000 

Analog  Input  Module 

811,688 

2,699,000 

Digital  Output  Module 

522,008 

8,512,000 

Analog  Output  Module 

237,192 

979,000 

Cumulative  Reliability 

92,296 

261,651 
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in  Table  6.  The  results  are  listed  at  the  bottom  of  Table  5  as  “Cumulative 
Reliability.”  The  formulas  specified  there  are  given  here  as  Equations  2  and  3.  This 
method  considers  failure  of  any  single  component  to  comprise  failure  of  the  entire 
unit. 


p  _  g(  t/MTBF) 


[Eq  2] 


where  t  =  1000  hr,  and 


Cumulative  MTBF  =  - 


1000 


Ln  (Cumulative  Reliability) 


[Eq  3] 


where  Cumulative  Reliability  =  R1  x  R2  x  R3  x  R4  x  R5. 


Table  1  lists  R1  through  R5. 


Software 

The  use  of  PLCs  for  HVAC  control  is  fairly  straightforward  if  one  does  not  require 
energy  management  application  software.  PLCs  can  perform  local  loop  control,  can 
be  networked,  have  available  data  acquisition  and  monitoring  packages,  and  in 
general  can  duplicate  the  functions  of  a  “commercial  DDC.” 

Various  tools  are  available  to  program  PLCs,  but  for  the  past  26  years,  graphical 
relay  ladder  logic  programming  has  been  used  the  most.  Graphical  relay  ladder 
logic  programming  evolved  directly  from  the  wiring  diagrams  used  to  hard- wire  the 
relay  panels  that  the  PLC  replaced.  In  the  original  relay  ladder  logic  diagrams, 


Table  6.  Point  configuration  for  VAV  AHU. 


Type 

Al 

AO 

Dl 

DO 

Total 

5 

3 

7 

1 

Description 

Return  air  temp. 

Mixed  air  temp. 

Fan  filter  switch 

Fan  on 

Outdoor  air  temp. 

Fan  speed 

Fan  proving  switch 

Mixed  air  temp. 

Chilled  water  coil 

Freeze  stat 

Supply  air  temp. 

Supply  air  smoke  alarm 

Static  pressure 

Return  air  smoke  alarm 

Night  stat 

Auxiliary  fan  on  relay 
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symbols  representing  relay  contacts  and  coils  were  drawn  in  horizontal  lines 
arranged  like  the  rungs  of  a  ladder.  If  the  states  of  the  switches  within  a  particular 
rung  (which  represented  actual  inputs)  would  allow  power  to  flow  through  the 
rungs,  the  output  coil  (which  represented  an  actual  output)  would  be  turned  on. 
Programming  of  PLCs  for  logic  purposes  is  commonly  symbolized  with  a  ladder 
diagram.  Figures  9  and  10,  for  example,  show  a  generic  ladder  logic  diagram  for  a 
Single  Building  Dual  Temperature  Hydronic  system  as  defined  in  the  Army  Corps 
of  Engineers  technical  manual  on  HVAC  Controls  (U.S.  Army  Corps  of  Engineers 
Huntsville  Division  1987).  When  this  is  compared  to  a  hard-wired  relay  logic 
control  system,  the  advantages  of  PLCs  becomes  quite  apparent.  Other  functions, 
such  as  analog  input  scaling  and  comparison  functions,  are  typically  done  in  func¬ 
tion  blocks,  as  shown  generically  on  lines  1  and  2.  Lines  3  through  11  represent  all 
the  logic  required  to  select  the  different  modes  of  operation.  Lines  12  through  14 
determine  the  setpoint  of  the  hot  water  supply.  Lines  15  through  27  implement  the 
modes  of  operation. 

Over  time,  ladder  programming  has  become  more  powerful.  Timer  and  counter 
instructions  were  added.  Arithmetic  functions  (addition,  subtraction,  multiplica¬ 
tion,  and  division  of  values  stored  in  referenced  PLC  memory  locations)  were  also 
introduced.  Data  manipulation  instructions,  which  allow  data  comparison  (<,>,=), 
data  conversions,  and  other  multi-bit  operations,  have  also  become  part  of  the  lad¬ 
der  diagram  instruction  set.  As  the  need  for  more  and  more  sophisticated  mathe¬ 
matical  capabilities  became  apparent,  “special  function  blocks”  were  added  to  the 
programming  language.  Function  blocks  are  software  objects  representing 
specialized  control  functions.  A  user  can  apply  the  same  control  functionality 
repeatedly  by  encapsulating  it  in  function  block  form,  storing  the  function  block  in 
a  library,  and  then  installing  copies  of  the  function  block  as  many  times  as 
necessary  in  control  programs.  These  special  function  blocks  allow  the  user  to 
program  the  PLC  for  various  advanced  applications,  such  as  the  PID  loop  control. 

Differences  between  software  programs  available  from  PLC  vendors  can  vary  from 
minimal  menuing  differences  to  completely  different  methods  of  programming  and 
analysis.  Consequently,  the  “learning  curve”  can  also  vary.  For  instance,  a 
graduate  student  who  had  previously  programmed  using  only  one  PLC  interface 
was  able  to  successfully  program,  using  their  software,  a  second  vendor’s  PLC  to 
perform  as  a  VAV  panel,  in  20  hr.  This  procedure  included  installation  of  the 
software,  learning  the  new  interface,  programming,  and  debugging. 
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Figure  9.  Generic  ladder  logic  program. 


Figure  10.  Mode  implementation  ladder  logic. 
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This  was  possible  because  the  concept  of  ladder  logic  programming  is  universal. 
Some  interfaces  from  the  vendors,  however,  require  significant  learning  curves. 
The  same  student  required  twice  the  time  to  learn  and  program  another  PLC  for  the 
same  purpose. 

Although  ladder  logic  presently  remains  the  most  widely  used  programming  tool, 
other  programming  methods  are  rapidly  gaining  acceptance.  The  International 
Electromechnical  Committee  (IEC)  began  working  on  a  standard  PLC  programming 
language  in  1979.  The  current  standard,  IEC-1131-3,  defines  five  standard 
languages  for  PLCs: 

1.  Ladder  logic 

2.  Function  block  diagram 

3.  Sequential  function  chart 

4.  Instruction  list 

5.  Structured  text. 

The  first  three  programming  languages  are  graphical,  while  the  latter  two  are  text- 
based.  IEC-1131-3  has  made  programming  of  PLCs  more  uniform  for  programmers, 
system  integrators,  and  users.  The  five  different  languages  are  linked  into  a  single 
executable  program,  so  that  the  differences  of  those  five  languages  are  transparent 
to  the  user.  This  standard  has  had  a  greater  initial  acceptance  in  Europe,  but  is 
now  rapidly  gaining  acceptance  in  the  United  States,  where  the  ladder  logic  and 
Sequential  Function  Chart  (SFC)  are  still  the  primary  methods  used.  SFC  is  a 
method  for  grouping  ladder  logic  programs  into  blocks  associated  with  steps  within 
a  process.  Some  higher  level  languages  such  as  such  as  “C”  are  also  gaining 
acceptance  for  tasks  such  as  self  tuning,  which  require  sophisticated  mathematical 
capabilities,  but  the  primary  programming  tool  remains  in  ladder  logic  format  with 
a  graphical  interface  allowing  control  programs  to  be  easily  configured.  A  group, 
PLCOpen,  was  formed  to  support  the  IEC  standard.  PLCOpen  was  founded  in  June 
1992  and  consists  of  researchers,  PLC  manufacturers,  and  users.  This  group 
performs  the  many  functions  required  for  orderly  implementation  of  the  standard 
such  as  overseeing  conformance  testing,  accreditation,  updating,  etc. 

While  programming  and  limited  monitoring  and  data  acquisition  software  is 
typically  included  with  the  price  of  a  CPU  module  purchase,  the  proliferation  of 
third  party  software  for  PLC  programming  gives  the  user  many  choices  that  are 
often  superior  to  those  provided  by  the  original  manufacturer.  If  multiple  vendor 
PLCs  are  expected  to  be  involved,  a  programming  package  that  adheres  to  the  IEC 
1131-3  PLC  Programming  Standard  is  recommended.  This  allows  programming 
multiple  vendor  PLCs  with  no  requirement  to  learn  multiple  programming 
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environments  or  techniques.  Packages  to  program  PLCs  are  available  from  at  least 
29  different  sources  (Hager  1991)  and  every  day  more  of  them  are  becoming  com¬ 
pliant  with  IEC  1131-3. 

While  the  majority  of  the  third  party  PLC  software  vendors  provide  support  for 
several  PLC  brands,  some  specialize  in  supporting  single  vendors,  the  most  notable 
example  being  ICOM,  which  supports  Allen  Bradley  PLCs.  (Allen  Bradley  recently 
bought  ICOM.)  The  most  intriguing  package  to  come  to  market  recently  is 
CADEPA  from  Famic.  CADEPA  allows  the  purchase  of  a  driver  for  each  brand  of 
PLC  to  be  used.  Once  a  program  is  written,  the  driver  is  used  to  compile  the  pro¬ 
gram  for  the  target  PLC  hardware.  This  allows  programs  to  be  created  independ¬ 
ently  of  the  vendor  hardware  to  be  used.  This  particular  package  supports  seven 
different  vendors  including  Allen  Bradley  and  Siemens,  the  leading  PLC  vendor  in 
the  world.  Similar  packages,  such  as  Transys’  ISaGRAF,  adhere  to  IEC  1131-3. 
According  to  a  survey  by  Control  Engineering  (Pollard  1995),  of  11  vendors  provid¬ 
ing  PLC  programming  software,  all  but  one  plan  full  support  of  the  standard  by 
1996.  Continued  support  of  IEC  1131-3  is  assured  because  the  big  three  auto  manu¬ 
facturers  desire  it.  They  have  created  a  white  paper  “Requirements  of  Open,  Modu¬ 
lar  Architecture  Controllers  for  Applications  in  the  Automotive  Industry  (OMAC),” 
which,  among  other  things,  requires  the  ability  to  use  the  IEC  programming 
standard. 

Central  monitoring  functions  such  as  report  generation,  data  collection,  etc.  for 
PLCs  is  also  most  easily  done  with  third  party  products.  They  provide  operator 
interfaces  with  drivers  for  hundreds  of  devices  with  minimal  configuration  require¬ 
ments  for  multiple  vendors. 

Off-the-shelf  application  programs  to  perform  supervisory  control  with  PLCs  do  not 
exist;  however,  most  of  the  commonly  used  ones  such  as  scheduled  start/stop, 
demand  limiting,  economizer,  day-night  setback,  and  resets  can  be  easily  imple¬ 
mented  in  the  ladder  logic  PLC  program.  In  addition,  third  party  tools  with  a 
graphical  programming  interface  to  create  the  remaining  functions  are  plentiful. 
USACERL  has  completed  a  Small  Business  and  Innovative  Research  (SBIR)  project 
to  develop  supervisory  energy  management  programs  and  expects  to  have  a  proto¬ 
type  system  at  its  HVAC  Test  Facility.  Additionally,  Fort  Sam  Houston,  San 
Antonio,  Texas,  is  using  PLCs  for  HVAC  control  based  on  the  prototype  at  the  Test 
Facility. 

Some  of  the  more  sophisticated  energy  management  functions  such  as  optimum 
start/stop,  which  are  infrequently  used  in  the  Army,  would  require  capabilities  more 
sophisticated  than  ladder  logic  and  function  blocks,  capabilities  that  sequential 
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function  charts  can  easily  accommodate.  Fortunately,  many  PLCs  have  the  optional 
capability  of  programming  in  a  high  level  language  such  as  “C,”  which  is  supported 
in  the  instruction  list  and  structured  text  options  of  IEC  1131-3. 


Operation 

To  qualify  for  application  to  industrial  processes  a  PLC  must  be  able  to  monitor  its 
I/O  constantly  when  in  the  run  condition.  This  process  of  sequentially  reading  the 
inputs,  executing  the  program  in  memory,  and  updating  the  outputs  is  known  as 
“scanning.”  The  scan  process  generally  has  four  phases,  which  are  repeated 
continuously  as  individual  cycles  of  operation  when  the  PLC  is  in  the  run  mode. 
While  all  PLCs  do  not  scan  exactly  in  this  manner,  they  all  perform  these  phases 
as  the  program  is  executed. 

Phase  1 — input  Status  Scan 

Each  cycle  begins  with  an  input  status  scan.  Here,  sensor  readings  are  gathered 
into  a  reserved  portion  of  memory  called  the  input  status  memory.  This  phase  is 
carried  out  as  a  single  step,  uninterrupted  by  other  operations,  to  provide  a  clear 
snapshot  of  the  state  of  the  process  at  a  given  instant. 

Phase  2 — Program  Execution 

The  user  program  is  executed  by  the  microprocessor,  all  values  in  the  input  status 
memory  are  examined,  required  calculations  and  logic  functions  are  performed,  and 
the  results  are  stored  in  a  reserved  portion  of  memory  called  the  output  status 
memory. 

Phase  3 — Output  Status  Scan 

This  scan  sends  the  stored  output  values  to  actuators  and  field  output  devices. 

Phase  4 — Memory  Word  Zero 

In  this  scan,  the  processor  performs  some  housekeeping  or  overhead  operations 
called  memory  word  zero  time.  These  overhead  functions  include  diagnostic  checks 
on  the  PLC  as  well  as  service  of  peripheral  devices  such  as  loader/terminals  and 
communications  interfaces.  As  soon  as  these  tasks  are  completed,  the  entire  cycle 
begins  again  with  another  input  status  scan. 
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Local  HVAC  Control  and  Energy  Management  Applications 

Unlike  Commercial  DDC,  PLC  vendors  do  not  typically  have  packaged  HVAC 
controls  or  energy  management  applications.  USACERL  has  worked  for  the  past 
2  years  under  the  Small  Business  Innovative  Research  (SBIR)  program  to  develop 
them.  The  results  of  this  project  are  very  encouraging.  The  systems  integrator 
(Team  Controls  of  Dallas,  TX)  has  developed  local  controls  for  12  of  the  17  standard 
air  handler  and  hydronic  systems  described  in  TM  5-815-3.  Since  they  were 
developed  using  an  IEC1131-3  compliant  programming  package,  they  are 
transportable  to  various  PLC  vendor  platforms  as  previously  described.  They  have 
also  developed  four  energy  management  programs:  Demand  Limiting,  Scheduled 
Start/Stop,  Optimum  Start/Stop,  and  Night  Setback.  These  programs  eliminate  the 
largest  obstacle  to  the  use  of  PLCs  in  HVAC  applications.  As  part  of  the  SBIR 
project,  the  contractor  has  also  set  up  a  working  demonstration  of  multiple  vendor 
PLCs  controlling  HVAC  systems.  Figure  11  shows  a  diagram  of  the  demonstration. 


Trends  and  the  Future 

The  development  of  an  open  architectures  within  the  PLC  industry  is  a  trend  that 
has  the  potential  to  change  the  industrial  control  industry  the  same  way  that  the 
open  architecture  of  the  IBM  personal  computer  changed  that  industry.  It  is 
presently  possible,  for  instance,  to  purchase  a  “brand  X”  PLC  and  connect  to  it  both 


Figure  11.  USACERL  PLC  HVAC  controls  and  energy  management  demonstration 
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brand  X  and  brand  Y  I/O.  The  most  significant  example  of  this  is  the  ability  that 
the  new  Modicon  family  of  controllers  has  to  directly  access  information  from 
LonWorks  devices.  In  the  past,  vendors  realized  the  majority  of  profits  from  the 
sale  of  I/O  modules.  Because  of  that,  they  sold  other  units  such  as  the  CPU  and 
backplane  at  very  inexpensive  rates  and  charged  correspondingly  higher  rates  for 
I/O.  This  gave  them  very  strong  incentives  to  keep  the  communications  on  the  back¬ 
plane  proprietary  so  that  only  their  brand  of  I/O  could  be  used.  This  ability  to  open 
up  PLC  I/O  communications  is  therefore  seen  as  very  significant.  It  focuses  efforts 
on  service  and  to  some  degree  away  from  hardware.  PLCs  then  are  becoming  a 
commodity  to  be  bought  from  the  source  with  the  lowest  cost. 

Another  interesting  trend  within  the  PLC  industry  (which  parallels  a  similar  trend 
within  the  controls  industry  in  general)  is  the  migration  of  intelligence  closer  to  the 
field  devices.  As  microprocessor  technologies  develop,  it  becomes  feasible  and  cost 
effective  to  develop  micro-PLCs  that  can  be  essentially  dedicated  to  small 
applications.  Other  facets  of  this  trend  is  the  development  of  “smart  I/O”  that  can 
communicate  with  PLCs  over  twisted  pair  cables,  perform  self-diagnostics,  and 
protect  against  short  circuits.  One  vendor  (GESPAC)  claims  that  its  smart  I/Os  are 
even  capable  of  continuing  to  collect  data,  provide  supervisory  control  and  maintain 
interaction  between  up  to  8,000  I/O  points,  even  if  the  twisted  pair  network  back  to 
a  host  PC  fails.  In  addition,  these  modules’  internal  calendar  clock  enable  them  to 
perform  daily  or  weekly  time-based  functions  as  well  as  time  stamp  alarm  messages 
and  generate  interrupts  on  a  host  PC.  The  significance  of  this  will  depend  on  the 
development  of  a  standard  communications  protocol. 

One  of  the  most  important  trends  in  any  controls  environment  today  is  standardiza¬ 
tion  of  communications.  The  Instrument  Society  of  America  (ISA)  Standards 
Project  Committee  (SP50)  is  currently  developing  a  standard  communications 
protocol  for  industrial  controls.  ISA’s  SP50  committee  is  the  North  American  par¬ 
ticipant  in  a  world-wide  effort.  Currently,  the  work  of  the  Interoperable  Systems 
Project  (ISP),  which  merged  with  WorkdFIP  and  uses  a  majority  of  the  SP50  work, 
is  the  most  likely  candidate  to  develop  an  accepted  communications  standard  for 
industrial  controls.  ISP  has  several  ongoing  and  planned  demonstrations  that  use 
varying  degrees  of  the  proposed  standard.  Ambitious  goals  of  having  a  finalized 
standard  in  1996  could  significantly  affect  the  control  market  once  they  are  realized. 

If  current  trends  continue,  the  standardization  of  programming  PLCs  using  the  IEC 
1131-3  standard  can  be  expected  to  accelerate.  In  the  near  future,  programs  devel¬ 
oped  to  be  fully  portable  between  PLCs  will  decrease  development  costs  and 
increase  the  efficiency  with  which  problems  with  programs  and  processes  can  be 
diagnosed  and  resolved. 
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4  Single-Loop  Digital  Controller 


Background 

Single-loop  digital  controllers  (SLDCs)  are  the  digital  counterparts  of  pneumatic 
and  electronic  analog  controllers.  The  SLDC  evolved  out  of  a  need  by  the  Process 
Industry  for  better  control  equipment  to  run  the  process  applications.  At  the  time 
of  its  inception,  the  SLDC  offered  the  process  industry  stable,  reliable,  local  control 
in  a  device  that  was  modular  and  virtually  maintenance  free.  SLDCs  have  been 
used  for  more  than  a  decade  in  manufacturing  process  controls  in  harsh  industrial 
environments  such  as  steel  mills,  refineries,  paper  mills,  and  chemical  processes. 
The  cost  of  SLDCs  was  previously  too  high  for  all  but  the  most  critical  applications; 
when  compared  to  multi-loop  DDCs,  they  are  still  more  expensive  on  a  first  cost 
basis.  They  do,  however,  offer  benefits  that  multi-loop  control  does  not.  The  single¬ 
loop  controller  itself  is  inherently  more  reliable  than  multi-loop  and,  combined  with 
the  reliability  of  the  individual  controllers,  results  in  the  most  reliable  control  of  the 
available  choices. 


Hardware 

SLDCs  are  industrial-grade  quality  controllers  designed  for  control  of  single  loops. 
Typically  packaged  in  a  rectangular  enclosure,  SLDC  usually  indicates  parameters 
on  one  or  two  digital  displays  that  can  be  sequenced  to  view  the  desired  parameter 
by  a  pushbutton.  Options  such  as  process  variable  sensor  type,  number  of  alarm 
outputs,  control  signal  type,  and  communication  capabilities  can  be  selected  at  the 
time  of  pin-chase,  allowing  an  interface  to  virtually  any  system.  Because  they  were 
designed  for  single  loops,  they  typically  have  only  one  or  two  of  each  I/O  (AI,  DI,  AO, 
DO). 

Perhaps  the  most  appealing  feature  of  SLDCs  is  the  apparent  acknowledgment  by 
manufacturers  that  users  desire  interchangeable  hardware.  This  is  reflected  in  the 
similarities  of  SLDC  packaging.  A  survey  of  30  SLDC  manufacturers  concluded 
that:  “The  packaging  of  single-loop  controllers,  insofar  as  their  external  dimensions 
and  panel  cutouts,  has  become  far  more  standardized  (as  compared  to  that  of  elec¬ 
tronic  analog  controllers),  with  increased  adherence  to  DIN  and  Namur  standards 
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in  particular,  ensuring  a  basic  level  of  compatibility,  enabling  replacement  and 
enhancements  to  be  carried  out  more  readily”  (Ingrey  1988).  The  DIN  standard 
referred  to  is  1/4  DIN  standard,  which  is  92mm  by  92mm  (3.62  in  by  3.62  in).  With 
standardized  design  SLDCs  are  interchangeable  between  manufacturer  and 
application;  if  one  of  the  SLDCs  in  an  HVAC  panel  needs  to  be  replaced,  it  can  be 
removed  and  replaced  with  a  generic  component.  Consequently,  users  can  maintain 
equipment  with  a  minimum  of  inventory. 

SLDCs  come  with  varying  degrees  of  sophistication,  and  corresponding  differences 
in  cost.  The  more  expensive  models  provide  extensive  math,  logic  and  signal¬ 
conditioning  functions,  and  multi-variable  input.  Typical  prices  are  from  $300  to 
$1,000. 

To  take  full  advantage  of  the  interchangeable  capability  of  SLDCs,  it  is  necessary 
to  specify  certain  features.  The  following  are  recommended  as  minimum  require¬ 
ments  (Schwenk  1988): 

•  end-user  selectable  P  only,  PI,  or  PID  control  mode 

•  operator  initiated-tune  capability 

•  automatic  (PID)  or  manual  control  mode 

•  single  4-1/2  digit  display  that  provides  display  of: 

-  setpoint 

-  process  variable 

-  output 

•  4  to  20mA  field  scalable  process  variable  input 

•  4  to  20mA  output 

•  user-selectable  maximum  control  signal  output 

•  user-selectable  local  or  remote  setpoint 

•  two  alarms,  each  with  a  mechanical  relay  contact  output  for: 

-  low  (or  high)  deviation  alarm 

-  absolute  (process  variable)  alarm 

•  user-selectable  alarm  hysteresis  (deadband) 

•  anti-reset  windup  (PID  algorithm) 

•  +/-  0.3  percent  accuracy 

•  5-year  retention  of  configured  data. 

A  control  panel  that  meets  specifications  of  TM  5-815-3  for  the  VAV  air  handling 
unit  described  earlier  can  be  obtained  for  approximately  $6,000.  Control  panels 
that  meet  specifications  of  TM  5-815-3  can  be  obtained  for  approximately  $5,800  for 
panels  with  a  small  number  of  controllers  (two)  to  $8,600  for  panels  with  a  larger 
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number  of  controllers  (six)  including  drawings,  data  sheets,  and  commissioning 
instructions  (based  on  pricing  of  panels  built  for  Fort  Hood  by  Johnson  Controls). 


Software 

SLDCs  typically  have  LCD  front  panel  displays  for  viewing  process  conditions  and 
configurable  parameters  such  as  PID  constants.  Parameters  such  as  alarm  levels, 
sensor  range,  and  actuator  range  are  typically  firmware  parameters  selected.  (A 
sequence  of  keystrokes  on  the  front  of  the  controller  changes  the  parameters  of  a 
permanent,  built-in  program,  typically  stored  in  Electrically  Erasable  Programma¬ 
ble  Read  Only  Memory  [EEPROM].)  Because  of  the  built-in  display  (even  though 
it  is  usually  limited  to  between  15  and  20  characters)  and  the  preprogrammed 
design,  there  is  no  requirement  for  a  computer  interface. 

Self-tuning  is  a  software  feature  of  SLDCs  that  is  very  appealing  to  utility  controls 
such  as  HVAC.  This  algorithm  is  built  into  the  controller,  which  selects  control 
parameters.  This  feature  can  be  a  great  labor-saving  device  and  routinely  selects 
more  appropriate  control  parameters  in  less  time  than  the  typical  trial-and-error 
methods  employed  on  systems  without  self-tuning.  A  previous  USACERL  study 
thoroughly  investigated  this  feature  (Underwood  1989).  The  operator  need  only  get 
the  process  to  be  controlled  in  a  steady  state  condition  and  push  the  self-time  button 
to  instruct  the  controller  to  calculate  new  control  parameters. 


Operation 

Ease  of  operation  is  one  of  the  SLDCs  strong  selling  points.  Through  the  use  of 
several  pushbuttons  (eight  is  typical)  and  LCD  or  LED  displays,  menus  allow  a 
large  degree  of  configuration  or  tailoring  of  the  controller  to  the  process  to  be 
controlled.  No  programming  is  required;  the  operations  are  permanently  stored  in 
the  controller.  Although  not  an  altogether  simple  procedure,  configuration  is  fairly 
straightforward  and  can  be  performed  quickly  and  easily  if  the  user  is  familiar  with 
the  process  and  terminology  used  by  the  controller.  Since  all  configuration  is  done 
through  a  menuing  question-and-answer  type  of  interface  that  pertains  only  to  that 
loop,  the  user  does  not  have  to  sort  through  large  data  base  entries  that  networked 
systems  typically  have. 
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Trends  and  the  Future 

In  the  near  future,  SLDCs  will  likely  begin  to  have  features  that  are  currently  an 
option  as  a  standard  feature.  Self  tuning,  adaptive  control,  and  serial  communica¬ 
tions  for  the  purpose  of  networking,  for  instance,  will  likely  be  a  common 
denominator.  The  basic  functionality  of  control  of  a  single  loop  will  remain  a 
popular  solution  for  a  certain  niche  of  controls.  Because  SLDCs  are  an  industrial 
controls  device,  standard  communications  developed  for  PLCs  will  likely  affect  them 
in  the  same  way. 
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5  Commercial  DDC 


Background 

In  the  1970s,  control  companies  began  producing  microprocessor-based  hardware 
for  the  monitoring  and  supervisory  control  of  HVAC  systems.  Specialized  software 
was  also  created  to  perform  control  functions  such  as  setpoint  reset  and  time 
scheduling.  These  systems  were  known  as  Energy  Management  and  Control 
Systems  (EMCS).  The  typical  EMCS  provided  a  large  number  of  energy  manage¬ 
ment  and  conservation  programs  to  the  operator: 


•  scheduled  start/stop 

•  duty  cycling 

•  day/night  setback 

•  ventilation/recirculation 

•  reheat  coil  reset 

•  hot  water  boiler  selection 

•  chiller  selection 

•  condenser  water  reset 

•  lighting  control 


optimum  start/stop 

demand  limiting 

economizer 

hot/cold  deck  reset 

steam  boiler  selection 

hw  oa  reset 

chilled  water  reset 

chiller  demand  limit 

remote  boiler  monitoring  control. 


While  all  of  these  are  usually  provided,  only  a  fraction  are  used  at  a  typical 
installation. 


The  high  cost  of  computing  hardware  dictated  that  these  early  systems  consist  of 
a  mainframe  computer  that  performed  all  supervisory  functions.  The  modulating 
control  of  devices  such  as  water  flow  valves  was  usually  done  locally  with  pneumatic 
controls.  The  cost  of  computing  hardware  decreased  slowly  at  first  and  has 
accelerated  recently,  resulting  in  a  greater  distribution  of  DDC  hardware  to  the 
field.  The  more  common  topology  these  days  is  to  have  the  local  controls  performed 
by  DDC.  The  DDC  standalone  control  panels  communicate  to  a  central  point 
usually  through  a  local  area  network. 

Advances  in  technology  and  associated  cost  reductions  in  hardware  have  made  the 
centralized  computing  configuration  an  outdated  design.  Although  a  few  manu¬ 
facturers  still  bid  systems  in  the  old  configuration,  largely  due  to  the  difficulty  in 
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translating  the  software  from  the  mainframe  to  centralized  personal  computer  sized 
hardware.  In  the  immediate  future,  nearly  all  control  systems  for  HVAC  will  be 
directly  controlled  with  standalone  intelligent  field  panels.  This  does  not 
necessarily  mean  that  the  hardware  will  be  in  the  form  of  the  typical  suppliers  of 
the  past.  Hardware  originally  intended  for  general  purpose  data  acquisition  or  the 
process  industries  must  also  be  considered. 


Hardware 

Commercial  DDC,  or  that  control  hardware  that  is  initially  designed  for  commercial 
applications  such  as  HVAC,  is  available  with  differing  degrees  of  modularity. 
Application-specific  or  “unitary”  controllers  such  as  those  used  to  control  a  chiller, 
heat  pump,  or  packaged  air  conditioner,  have  a  fixed  limited  number  of  I/O  points, 
a  fixed  program,  and  few,  if  any  user-definable  database  parameters.  The  charac¬ 
teristics  of  these  devices  are  established  at  the  time  of  manufacture,  much  like 
those  of  SLDCs.  Another  version  of  the  application  specific  controller  (ASC)  is  the 
“application  selectable  controller,”  which  has  a  library  of  selectable  programs  for 
applications  with  similar  numbers  of  I/O  requirements. 

In  contrast  to  the  ASC,  general  purpose  controllers  are  typically  more  modular,  are 
field  programmable,  and  may  have  a  sophisticated  operator  interface.  These 
general  purpose  controllers  are  generically  known  as  “Remote  Control  Units”  or 
“RCUs,”  standalone  smart  panels  that  provide  monitoring  and  control  functions. 
RCUs  maintain  their  own  database  but  update  a  central  station  database  either 
periodically  or  on  request. 

Field  panels  usually  have  battery  backups  to  keep  them  operating  for  at  least  8 
hours  in  the  event  of  a  power  loss.  There  are  two  types  of  panels,  general  purpose 
and  the  specialized.  A  general  purpose  panel  can  be  used  in  almost  any  application 
if  the  correct  number  of  input  output  channels  are  available.  A  specialized  panel 
has  been  designed  to  control  a  specific  piece  of  hardware,  such  as  an  air  handler. 


Software 

The  programming  of  field  panels  in  the  “Commercial  DDC”  hardware  is  very 
different  from  that  of  PLCs.  In  the  past,  it  involved  writing  programs  in  a  high 
level  language,  typically  a  specialized  language  developed  specifically  for  that 
family  of  control  hardware.  This  extremely  inflexible  aspect  of  traditional  DDC  still 
exists  to  some  extent.  Not  only  is  each  language  very  different  between  vendors, 
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but  any  specific  language  may  be  available  from  only  one  vendor.  Some  vendors 
now  offer  software  that  uses  a  graphical  interface,  greatly  decreasing  the 
programming  expertise  required  to  configure  the  field  panel,  but  again,  the  software 
remains  available  from  only  that  vendor.  Other  methods  used  include  template 
programming  and  Question-and-Answer  (Q&A)  programming.  The  template 
method  is  often  used  to  specify  the  functionality  of  simple  fixed  function  controllers, 
such  as  SLDC.  It  is  also  used  for  some  commercial  DDC  application  specific 
controllers.  The  Q&A  method  is  similar  to  a  multiple  choice  exam;  the  user  answers 
a  series  of  questions  with  a  limited  number  of  responses. 

While  much  work  is  being  done  on  a  standard  communications  protocol  for 
“commercial  DDC,”  none  has  begun  on  standardization  of  programming  Some 
application-specific  DDC  controllers  have  fixed  control  programs  that  cannot  be 
altered,  thereby  completely  eliminating  the  need  for  programming  at  that  level. 
Such  programs  are  limited  to  extremely  common  applications,  however,  because  of 
the  inflexible  nature  of  a  preprogrammed  panel. 


Operation 

Most  commercial  DDC  systems  provide  an  Operator  Machine  Interface  (OMI), 
which  can  display  data  in  either  a  report  or  graphic  format.  The  OMI  provides 
remote  monitoring  functions  across  wide  geographical  areas.  Data  analysis  is 
usually  provided  for  at  the  OMI  consisting  of  data  archival,  report  generation,  and 
use  of  adjunct  third  party  software  such  as  spreadsheets.  The  Microsoft  Dynamic 
Data  Exchange  (DDE)  standard  is  typically  used  to  facilitate  this  data  exchange. 

Much  like  that  of  the  PLC  local  interfaces,  users  have  choices  from  a  laptop  per¬ 
sonal  computer,  a  small  built-in  LCD  or  LED  display,  or  a  specially  designed 
handheld  device. 

Supervisory  control  programming  for  “traditional  DDC”  exists  off-the-shelf.  Some¬ 
times  this  programming  is  provided  as  part  of  the  control  hardware,  but  the  soft¬ 
ware  typically  requires  modification  to  meet  application-specific  needs;  such  modi¬ 
fication  can  be  a  significant  expense.  The  package  usually  consists  of  an  interface 
used  to  alter  parameters  that  are  part  of  a  database  that  the  packaged  software 
accesses.  For  instance,  the  procedure  for  setting  up  start/stop  times  using  the  DDC 
system  at  USACERL  was  as  follows.  First  the  menu  interface  system  is  used  to 
select  the  Tables  function.  The  menu  interface  is  then  used  to  select  Control 
Start/Stop.  This  displays  a  table  of  the  points  identified  in  the  data  base  as 
start/stop  points.  Adding  a  point  to  this  table  identifies  it  as  a  start/stop  point,  but 


USACERL  TR  97/87 


37 


does  not  specify  the  actual  start/stop  times.  This  is  done  by  maneuvering  back  to 
the  main  menu  and  selecting  the  Energy  Management  function  and  then  selecting 
the  Schedules  function.  This  accesses  the  start/stop  times  in  the  database,  which 
are  displayed  in  a  table  that  can  be  edited  using  the  arrow,  =,  and  number  keys. 


Trends  and  the  Future 

The  state-of-the-art  Building  Automation  System  (BAS),  or  DDC  system,  consists 
of  personal  computer-based  operator  consoles  and  standalone,  intelligent  field 
panels  that  provide  local  control  and  networking  capabilities.  As  with  the  older 
EMCS  systems,  the  point  of  centralized  data  collection  commonly  is  known  as  the 
“Central  Station.”  In  contrast  to  past  systems,  the  current  and  future  Central 
Station,  or  OMI,  serves  primarily  as  a  user  interface  to  the  system.  The  most 
typical  Central  Station  is  an  IBM-compatible  personal  computer. 

Field  panels  operating  in  a  standalone  mode  will  get  smaller,  more  powerful, 
specialized,  and  further  out  into  the  field.  They  will  communicate  with  the  central 
operator  workstation  through,  and  to,  other  devices.  Communication  between 
panels  and  the  central  operator  workstation  will  be  both  master-slave  and  peer-to- 
peer. 

The  trend  of  all  controls,  regardless  of  their  nature,  is  to  distribute  intelligence 
further  into  the  field.  To  facilitate  this,  a  standard  communications  protocol  is 
needed.  For  commercial  DDC,  this  means  BACnet™  (Building  Automation  Control 
network).  BACnet  is  a  standard  communications  protocol  being  developed  by  the 
American  Society  of  Heating,  Refrigeration,  and  Air  Conditioning  Engineers 
(ASHRAE),  a  large  professional  nonprofit  organization  of  engineers,  consultants, 
and  other  professionals.  SPC-135  (Special  Projects  Committee)  is  the  ASHRAE 
committee  that  has  been  developing  a  standard  communications  protocol  for  build¬ 
ing  automation  systems  since  January  1987.  The  committee  consists  of  members 
from  several  manufacturers,  academia,  and  researchers.  Some  of  the  members  are 
Andover  Controls,  American  Auto-Matrix,  Barber  Coleman,  Energyline,  Honeywell, 
Landis  &  Gyr  Powers,  Robertshaw  Controls,  Staefa  Control  Systems,  Trane  Uni¬ 
versal  Software,  Johnson  Controls,  NIST,  Cornell  University,  and  Public  Works 
Canada. 

The  BACnet  standard,  an  ASHRAE  and  ANSI  standard  (135-1995),  states  that  its 
purpose  is:  “To  define  data  communication  services  and  protocols  for  computer 
equipment  used  for  monitoring  and  control  of  HVAC&R  and  other  building  systems 
and  to  define,  in  addition,  an  abstract,  object-oriented  representation  of  information 
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communicated  between  such  equipment,  thereby  facilitating  the  application  and  use 
of  digital  control  technology  in  buildings.” 

BACnet™  in  its  present  form  provides  for  five  combinations  of  the  first  two  layers 
(Physical  and  Data  Link)  of  the  ISO  seven-layer  communications  protocol:  “BACnet 
is  based  on  a  four-layer  collapsed  architecture,  which  corresponds  to  the  physical, 
data  link,  network,  and  application  layers  of  the  OSI  model.  The  application  layer 
and  a  simple  network  layer  are  defined  in  the  BACnet  standard. 

BACnet  provides  five  options  that  correspond  to  the  OSI  data  link  and  physical 
layers: 

•  Option  1  is  a  logical  link  control  (LLC)  protocol  defined  by  ISO  8802-2  Type  1, 
combined  with  the  ISO  8802-3  Medium  Access  Control  (MAC)  and  physical 
layer  protocol.  ISO  8802-2  Type  1  provides  unacknowledged  connectionless 
service  only.  ISO  8802-3  is  the  international  standard  version  of  the  well- 
known  “Ethernet”  protocol. 

•  Option  2  is  the  ISO  8802-2  Type  1  protocol  combined  with  ARCNET  (ATA/ 
ANSI  878-1). 

•  Option  3  is  a  master-slave/token-passing  (MS/TP)  protocol  designed  specifi¬ 
cally  for  building  automation  and  control  devices  as  part  of  the  BACnet 
standard.  The  MS/TP  protocol  provides  an  interface  to  the  network  layer  that 
looks  like  the  ISO8802-2  Type  1  protocol  and  controls  access  to  an  IEA-485 
physical  layer. 

•  Option  4,  the  Point-To-Point  protocol,  provides  mechanisms  for  hardwired  or 
dial-up  serial,  asynchronous  communication. 

•  Option  5  is  the  LonTalk  protocol. 

Collectively,  these  options  provide  a  master-slave  MAC,  deterministic  token-passing 
MAC,  high  speed  contention  MAC,  dial-up  access,  star-and-bus  topologies,  and  a 
choice  of  twisted  pair,  coax,  or  fiber  optic  media.  The  details  of  these  options  are 
described  in  clauses  7  through  10  (ASHRAE,  p  9). 

“To  assist  in  the  specification  of  BACnet  devices,  the  standard  includes  as  an  annex 
for  information  purposes  a  “Protocol  Implementation  Conformance  Statement.” 
This  summarizes  in  a  tabular  format  the  6  conformance  classes,  13  functional 
groups,  18  standard  object  types,  35  application  services,  and  data  link  layer  options 
defined.  A  conformance  class  specifies  a  minimum  set  of  services,  objects,  and 
properties,  which  the  device  must  support  to  claim  membership  in  a  particular 
class.  The  conformance  classes  are  numbered  1  to  6  and  are  hierarchial  in  nature. 
The  requirements  for  each  class  include  all  of  the  requirements  of  all  of  the  other 
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classes  with  a  lower  number.  Conformance  Class  1,  for  example,  requires  that  the 
execution  of  the  ReadProperty  Application  Service  on  a  Device  object  type  be 
supported.  Class  2  requires  that,  in  addition  to  supporting  the  Class  1  require¬ 
ments,  the  device  must  also  support  the  execution  of  the  WriteProperty  Application 
Service.  Table  7  lists  the  13  functional  groups  that  define  a  combination  of 
Application  Services  and  Standard  Object  Types.  Table  8  lists  the  18  Standard 
Object  Types  that  define  information  groups  and  their  organization. 

Devices  can  be  expected  to  interoperate  with  respect  to  a  given  function  if  they  are 
in  the  same  conformance  class  and  support  the  same  functional  groups.  The  extent 
to  which  such  a  system  could  actually  be  built  depends  on  the  devices  that  vendors 
choose  to  provide.  A  designer  could  theoretically  use  combinations  of  Standard 
Object  Types,  Application  Services,  and  Conformance  Classes  to  procure  an  inter¬ 
operable  system.  The  extent  to  which  this  will  be  possible  depends  on  the  actions 
of  the  controls  vendors. 

Initially  BACnet™  will  not  result  in  “plug  and  play  compatibility”  (the  capability 
to  replace  a  device  from  one  vendor  with  another  with  no  loss  of  any  functionality 
or  reconfiguration  of  other  devices).  In  fact,  BACnet™  neither  precludes  nor 
ensures  plug  and  play  compatibility.  Moreover,  plug  and  play  compatibility  will 
probably  not  happen  any  time  in  the  near  future,  if  it  happens  at  all.  The  first 
BACnet™  compatible  products  will  very  likely  fall  into  two  categories:  (1)  field 
panels,  and  (2)  the  components  located  “beneath”  the  panels  in  the  control 
structure.  Many  companies  that  produce  products  with  packaged  controls  such  as 
chillers  will  produce  equipment  that  communicates  at  some  level  using  the 
BACnet™  standard.  HVAC  controls  vendors  will  very  likely  produce  field  panels 
that  communicate  to  the  primary  control  network  (the  one  connecting  multiple 
operator  workstations  and  primary  field  panels)  using  the  BACnet™  standard. 
These  primary  field  panels  will  very  likely  have  a  secondary  communication  net¬ 
work  for  other  equipment  such  as 
unitary  controllers,  which  will  be  pro¬ 
prietary.  This  would  not  necessarily 
mean  that  such  devices  will  not  be 
BACnet™  compatible.  It  depends  on 
what  parts  of  the  standard  a  product 
must  adhere  to  to  be  considered 
“BACnet™  compatible.”  Efforts  are 
under  way  to  define  conformance 
testing  methods  that  should  begin  to 
answer  such  questions. 


Table  7.  BACnet  functional  groups. 


Clock 

Virtual  Operator  Interface 

Hand-Held 

Workstation 

Virtual  Terminal 

Personal  Computer 
Workstation 

COV  Event  Initiation 

Event  Initiation 

COV  Event  Response 

Event  Response 

Device  Communications 

Files 

Time  Master 

Reinitialize 
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Vendors  are  already  building  prototypes  and 
a  few  vendors  are  already  marketing  finished 
products  based  on  the  proposed  standard. 
Products  adhering  to  the  final  standard  could 
conceivably  become  available  within  months 
or  even  weeks  after  the  standard  is  approved. 
Designers,  users,  and  others  cannot  expect, 
however,  to  begin  designing,  purchasing, 
installing,  and  using  standard  systems  based 
on  BACnet™  for  some  time  after  that.  A 
vendor  can  easily  claim  that  their  products 
are  100  percent  compatible  with  the  stan¬ 
dard.  Without  an  independent  evaluation  of 
this  claim,  however,  one  would  be  taking  great  risk  to  take  these  claims  at  face 
value.  Even  a  product  that  is  independently  evaluated  to  be  100  percent  BACnet™ 
compatible  must  be  evaluated  by  the  designer  to  determine  that  the  functionality 
of  the  device  in  terms  of  conformance  class,  functional  group,  object  types,  applica¬ 
tion  services,  and  data  link  option  meets  requirements. 


Table  8.  BACnet  standard  object  types. 


Analog  Input 

Device 

Analog  Output 

Event  Enrollment 

Analog  Value 

File 

Binary  Input 

Group 

Binary  Output 

Loop 

Binary  Value 

Multi-State  Input 

Calendar 

Multi-State  Output 

Notification  Class 

Program 

Command 

Schedule 
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6  STD  and  VME  Bus  Systems 


Background 

Industrial  versions  of  the  DOS-based  personal  computers  designed  specifically  for 
control  in  critical  applications  are  available  in  several  configurations.  Two  stan¬ 
dards  have  emerged  as  the  leaders  in  this  area,  STD  bus  (ANSI/IEEE  Std  961-1987) 
and  VME  bus.  These  standards  describe  various  mechanical  and  electrical  proper¬ 
ties  of  the  control  hardware  that  meet  the  needs  of  the  industrial  environment. 
These  standards  are  analogous  to  the  various  personal  computer  buses  such  as  ISA 
and  microchannel.  The  STD  bus  came  into  existence  in  1978  via  IEEE  Standard 
961  and  is  still  widely  used,  with  a  market  of  $90  million  and  over  500,000  installed 
systems  in  1991  (Seibert  1991). 

By  implementing  a  DOS  platform,  this  control  hardware  is  able  to  take  advantage 
of  all  the  PC  software  and  ease  of  software  development  environment  available  for 
the  PC.  STD  bus  has  an  active  manufacturers  group  (STD  MG)  that  monitors 
standards,  specifications,  and  new  technical  developments  to  ensure  orderly  evolu¬ 
tionary  growth.  Rather  than  abandon  the  old  standard  once  technology  passes  it 
up,  STD  bus  continues  to  support  a  migration  path  to  permit  existing  I/O  cards  to 
coexist  on  the  same  bus  with  future  and  past  I/O  cards.  STD- 16  bus,  adopted  by 
STD  MG  in  September  1991,  supports  32-bit  80386  and  other  CPUs.  Memory 
transfer  is  32-bit  on  card  and  16-bit  on  the  backplane.  STD32,  which  became  avail¬ 
able  in  1989  for  applications  that  require  a  more  powerful  platform,  is  a  proprietary 
bus.  The  original  STD  bus  is  based  on  an  8-bit  data  throughput  and  the  new  STD32 
bus  (introduced  in  1989)  allows  for  8-,  16-,  and  32-bit  data  throughput.  STD32  then 
is  backward  compatible  with  the  original  STD  bus.  For  example,  a  20  MHz  80386sx 
CPU  will  work  well  with  the  same  industrial  card  designed  for  the  original  8085. 
The  16-bit  STD  bus  architecture  is  quite  similar  in  power  and  functionality  to  the 
PC-AT  ISA  bus,  yet  is  designed  specifically  for  the  rigors  of  industrial  applications. 
Another  important  aspect  of  the  STD32  approach  is  the  Inter-Processor  Communi¬ 
cations  (IPC)  specification.  IPC  allows  single  board  computers  to  communicate  with 
each  other  over  the  common  bus.  This  is  done  through  a  bus  ARBITER  card,  which 
must  be  in  slot  X  of  the  backplane. 
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Hardware 

The  STD  and  VME  bus  standards  specify  the  many  mechanical  and  electrical  items 
necessary  to  integrate  CPU  boards,  I/O  boards,  and  peripheral  devices.  Hardware 
built  to  these  specifications  are  compatible  with  personal  computer  programs,  but 
differ  from  personal  computers  in  that  they  were  intended  for  use  in  harsh  environ¬ 
ments,  not  the  office.  Besides  the  processor  board,  other  boards  such  as  memory 
and  I/O  can  be  plugged  into  the  bus.  These  systems  use  the  DOS  operating  system 
and  can  communicate  over  a  variety  of  standard  networks.  Several  versions  exist 
of  both  types,  most  of  which  are  backward  compatible.  Dozens  of  manufacturers 
produce  hardware  compatible  with  this  standard.  Use  of  systems  based  on  this 
architecture  would  necessitate  the  development  of  application  software  for  the 
Army’s  specific  needs. 

STD  and  VME  bus  systems  are  highly  reliable.  Versalogic,  a  STD  bus  manufac¬ 
turer  reports  its  average  MTBF  of  individual  boards  to  range  between  15  and  45 
years.  Ziatech,  a  STD32  provider,  provides  boards  with  MTBF  ranging  from  10  to 
50  years. 


Software 

STD  and  VME  bus  systems  look  exactly  alike  from  the  software  perspective, 
because  they  have  similar  architectures  and  are  both  based  on  Intel  microproces¬ 
sors.  In  other  words,  they  are  compatible  with  software  developed  for  the  personal 
computer,  so  a  wide  variety  of  software  ranging  from  card  drivers,  network 
operating  systems,  spreadsheets,  and  control  software  is  available.  A  special  Basic 
Input  Output  System  (BIOS)  is  provided  that  tailors  the  DOS  desktop  oriented 
system  to  address  the  special  requirements  of  embedded  and  control  environments. 
This  is  in  fact  a  main  selling  point  of  these  systems.  Distributed  I/O  such  as 
Phoenix  Contact’s  InterBus-S,  GE  FAnuc  Genius  I/O,  Echelon’s  LONWORKs,  and 
Opto  22  are  supported. 


Operation 

Control  systems  based  on  STD  and  VME  standards  range  in  application  from 
embedded  control  on  subway  systems  to  controls  on  the  Space  Shuttle;  a  “typical” 
operation  is  difficult  to  describe.  Such  systems  do  not  depend  on  “off  the  shelf’ 
configurations,  but  are  based  on  specifically  tailored  hardware/software  setups  that 
may  involve  higher  setup  and  maintenance  costs. 
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It  was  mentioned  earlier  that  these  systems  are  extremely  rugged  and  reliable,  with 
MTBF  of  10  to  50  years.  They  are  also  very  easily  replaced  when  they  do  fail. 
Ziatech  includes  on  the  data  sheet  of  each  product  a  statistic  called  Mean  Time  To 
Replace  (MTTR).  For  most  boards  this  value  is  5  minutes. 


Trends  and  the  Future 

The  STD  bus  has  been  around  since  1978  and  continues  to  enjoy  widespread  use, 
largely  due  to  the  efforts  of  industry  groups  to  promote  backward  compatibility  of 
new  standards  when  taking  advantage  of  new  technology.  The  future  will  likely 
have  a  place  for  these  controls  as  well.  However,  the  first  cost  of  these  systems 
remains  high,  a  circumstance  that  prevents  them  from  being  applied  in  commercial 
applications  such  as  HVAC. 
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7  LonWorks 


Background 

A  collection  of  protocols,  publications,  products,  and  agreements  collectively  known 
as  LonWorks  has  over  the  last  several  years  begun  to  have  a  significant  impact  on 
the  controls  industry.  Because  this  affect  is  so  widespread,  it  cannot  be  associated 
with  any  single  type  of  control  system.  Applications  of  this  technology  include 
residences,  commercial  buildings,  utilities,  and  manufacturing  facilities  to  name 
only  a  few.  There  are  currently  many  debates  occurring  over  whether  LonWorks- 
based  technologies,  BACnet-based  technologies,  or  a  combination  of  the  two  will 
prevail  in  the  commercial  DDC  arena.  It  is  not  presently  clear  what  the  outcome 
will  be.  What  is  clear  is  that  LonWorks  technology  will  be  a  major  player  in  several 
industries. 

A  lot  of  confusion  exists  in  the  controls  industry  about  the  relation  of  these  two 
technologies.  Since  BACnet  was  previously  described,  this  section  concentrates  on 
LonWorks  and  its  relation  to  BACnet.  Just  as  the  key  of  a  BACnet-based  system 
is  the  BACnet  protocol,  the  heart  of  a  LonWorks  system  is  the  LonTalk  protocol. 
While  it  is  not  the  intent  here  to  explain  all  details  of  either,  enough  of  an 
explanation  is  attempted  to  understand  the  difference  between  the  two  and  what 
part  of  LonTalk  is  allowed  as  part  of  a  BACnet  system.  In  very  general  terms,  both 
protocols  have  in  them  descriptions  of,  among  other  things: 

•  a  collection  of  services 

•  a  collection  of  objects. 

The  services  allow  for  such  things  reading,  writing,  creating,  deleting,  and 
interrogation  of  objects.  The  point  to  be  made  here  is  that  the  way  this  is  done  is 
different  for  the  two  different  protocols.  Because  of  this,  they  are  not  seamlessly 
compatible.  This  does  not  mean  that  a  LonWorks  system  and  a  BACnet  system 
cannot  share  information.  It  does  mean  that  a  significant  amount  of  customization 
could  be  required.  The  key  to  these  customization  requirements  is  the  organization 
of  the  objects.  LonWorks  devices  communicate  primarily  with  what  are  called 
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Standard  Network  Variable  Types,  or  SNVTs  (pronounced  “snivits”).  SNVTs  are 
described  in  The  SNVT  Master  List  and  Programmer’s  Guide  (Echelon  publication 
005-0027-01).  These  are  easily  communicated  among  LonWorks  devices  by  implicit 
messages,  and  require  very  little  programming.  However,  since  these  are  not  the 
same  as  BACnet  objects,  communication  of  SNVTs  to  a  BACnet  device  requires 
significant  programming  of  the  device  via  the  use  of  explicit  messages.  The 
difference  is  significant.  The  following  analogy  should  clarify  the  difference.  An 
implicit  message  might  be  “Drive  to  the  store  and  get  me  some  bread.”  An  explicit 
message  would  be  much  longer,  such  as:  “Take  my  keys,  go  out  the  front  door,  close 
it  behind  you,  walk  to  my  car,  open  the  door,  get  in,  shut  the  door,  put  the  ignition 
key  in  the  ignition,  start  the  car,  put  it  in  gear...”  All  of  the  things  required  in  an 
explicit  message  are  automatically  taken  care  of  in  the  implicit  message.  The 
bottom  line  is  that  while  a  LonWorks  device  could  communicate  with  a  BACnet 
device,  it  is  by  no  means  guaranteed  to  be  an  easy  task. 

A  second  way  in  which  LonTalk  and  BACnet  differ  is  the  devices  for  which  the 
protocol  was  initially  targeted.  LonTalk  is  best  suited  for  devices  at  the  sensor  and 
actuator  level.  BACnet,  on  the  other  hand,  is  best  suited  for  field  panels  and 
operator  workstation  types  of  equipment.  As  previously  mentioned,  the  first  public 
demonstration  of  BACnet  consisted  of  field  panels  and  operator  workstations 
communicating  together,  not  field  devices.  Conversely,  conferences  and  exhibits 
that  include  LonTalk  technology  focus  on  the  field  devices  such  as  sensors  and 
actuators.  This  is  a  logical  distinction  that  follows  the  architecture  of  most  control 
networks  that  separates  communications  into  multiple  hierarchial  levels.  These 
levels  include  the  Information  Network,  the  Control  Network,  and  the  I/O  Network. 
Figure  12  depicts  how  these  three  network  levels  are  related.  The  function  of  the 
Information  Network  is  to  facilitate  communications  between  operator  workstations 
and  network  interface  devices.  The  Control  Network  facilitates  communications 
between  network  interface  devices  and  field  panels.  Finally,  the  I/O  Network 
makes  communications  between  field  panels  and  I/O  devices  possible.  All  levels  are 
not  always  readily  identifiable  as  a  separate  entity.  The  I/O  network  level  for 
instance  may  not  be  a  digital  communications  network  at  all,  but  a  combination  of 
4  to  20ma  and  binary  signals  instead.  In  some  cases,  the  Information  Network  and 
Control  Network  are  combined. 


Trends  and  the  Future 

LonWorks  technology  continues  to  evolve  and  enter  new  markets  daily.  The 
ongoing  development  of  functional  profiles,  standard  network  variables,  and 
Building  Automation  System  Master  Specifications  should  help  to  introduce  the 
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technology  to  Utility  Control  System  designers.  The  cost  sensitive  nature  of  the 
building  controls  industry  and  the  potential  cost  savings  of  LonWorks  based 
technology,  especially  the  reduced  wiring  costs,  give  reason  to  expect  LonWorks 
technology  to  be  used  extensively  in  the  right  markets.  Figure  12  shows  what  the 
next  generation  HVAC  control  system  will  likely  look  like.  BACnet,  if  involved,  will 
likely  function  as  the  Information  Network  and  possibly  Control  Network. 
Alternatively,  any  operator  machine  interface  with  communications  drivers  for  the 
various  Network  Interface  Device  could  be  used,  as  was  done  with  USACERL’s 
demonstration  of  PLCs.  LonTalk  will  function  at  the  I/O  network  level  and  very 
likely  as  part  of  the  Control  Network  as  well.  Control  vendors  and  users  with  a 
substantial  installed  base  have  a  very  strong  incentive  to  keep  the  Control  Network 
proprietary,  so  that  implementation  is  likely  to  be  encountered  where  existing 
equipment  is  to  be  reused. 

The  field  panels  of  the  future  will  also  look  quite  different  due  to  the  use  of  digital 
communications  with  sensors  and  actuators.  Devices  at  the  field  level  can  be 
described  in  two  classes.  One  class  of  device  includes  those  that  are  physically  close 
to  or  part  of  the  field  panel  because  it  is  desired  that  they  be  concentrated  into  one 
area.  These  include  manual  switches  such  as  Hand  Off  Auto  switches  and  pilot 
lights.  Another  class  of  device  includes  those  that  must  be  remotely  located  because 
of  the  physical  design.  These  include  zone  temperature  sensors,  thermostats, 
actuators,  and  alarm  devices  such  as  smoke  and  low  temperature  levels.  The  result 
of  this  reality  is  that,  despite  the  ability  to  remotely  locate  any  sensor,  actuator,  or 
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of  the  physical  design.  These  include  zone  temperature  sensors,  thermostats, 
actuators,  and  alarm  devices  such  as  smoke  and  low  temperature  levels.  The  result 
of  this  reality  is  that,  despite  the  ability  to  remotely  locate  any  sensor,  actuator,  or 
switch,  the  future  control  panel  will  still  have  hard-wired  (nondigital  communica¬ 
tion)  devices.  The  future  control  panel  will  therefore  look  something  like  that 
shown  in  Figure  13.  Pneumatics  will  remain  a  desired  form  of  actuation  and  will 
likely  remain  centralized  at  the  field  panel.  This  is  certainly  the  case  for  retrofit  of 
pneumatic  controls  where  pneumatic  lines  to  actuators  from  a  central  location 
currently  exist.  Pilot  lights  will  likely  be  direct  digital  outputs  of  the  field  panel. 
Reset  and  other  manually  initiated  field  switches  will  also  likely  be  located  at  the 
field  panel.  The  most  significant  change  will  be  the  elimination  of  all  home-run 
wiring  of  devices  that  must  be  remotely  located.  Instead,  one  set  of  wires  (from  two 
to  five  depending  on  the  transceivers  implemented)  will  be  run  from  the  field  panel 
to  one  device  then  from  that  device  to  the  next  and  so  on.  This  is  where  the 
installed  cost  savings  is  achieved.  Unfortunately,  this  increases  the  complexity  of 
the  system  since  digital  communication  is  inherently  more  complex  than  4  to  20ma 
signals.  Because  of  this  more  technical  nature,  there  are  certain  markets  such  as 
Army  Installations  in  which  implementation  of  the  technology  may  lag. 


Figure  13.  LonTalk  field  panel. 
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8  Summary  and  Recommendations 


Summary 

A  wide  variety  hardware  and  software  controls  are  available  for  use  in  Army 
utilities.  However,  some  Army  utilities,  such  as  HVAC,  have  unique  requirements 
that  are  not  always  met  by  “commercial  DDC.”  Hardware  such  as  Single  Loop 
Digital  Controllers  (SLDCs),  Programmable  Logic  Controllers  (PLCs),  and  indus¬ 
trialized  personal  computers  each  have  unique  capabilities  that  may  meet  these 
requirements. 

SLDC-based  controls  for  utilities  are  best  applied  to  standalone  applications.  Their 
reliability  and  ease  of  operation  for  maintenance  personnel  who  may  not  have  been 
to  the  process  location  for  a  long  period  of  time  gives  them  a  distinct  advantage  in 
these  applications.  While  a  life-cycle  cost  of  SLDC-based  controls  is  competitive 
with  alternatives,  they  are  relatively  expensive  on  a  first  cost  analysis.  They  are 
also  difficult  and  expensive  to  network.  Implementation  of  energy  management  or 
other  supervisory  actions  are  also  difficult  to  implement.  While  the  Interoperable 
Systems  Project  is  working  to  develop  a  standard  communications  protocol  that  may 
solve  networking  obstacles,  factors  such  as  the  relatively  high  first  cost  will  likely 
remain.  Because  of  their  very  nature,  global  functions  such  as  energy  management 
are  very  difficult  to  perform  without  incurring  extensive  additional  costs. 

Like  the  SLDC,  the  reliability  of  PLCs  is  also  much  greater  than  that  of 
commercially  based  controls.  Their  modular  design  and  reliability  provide  the 
possibility  for  an  economical  and  easily  maintained  control  system.  However,  since 
no  commercial  organizations,  large  scale  industrial  support,  or  developed  market 
for  PLC  control  of  HVAC  systems  yet  exist,  their  use  would  require  development  of 
programs  and  training  for  design  and  operations  persons.  This  is  especially  true  in 
the  Army  environment  where  routine  maintenance  may  fall  behind  schedule.  Their 
capability  to  be  networked  not  only  within  product  families,  but  also  with  other 
vendors  using  third  party  integration  software  and  de  facto  communication 
standards,  is  also  a  huge  attribute.  Standardization  of  PLC  programming  methods 
via  IEC1 131-3  is  unique  and  many  years  ahead  of  any  other  control  hardware.  A 
Small  Business  and  Innovative  Research  (SBIR)  project  to  develop  and  com¬ 
mercialize  Energy  Management  programs  for  PLCs  using  this  standard  has  the 
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potential  to  standardize  programs  within  control  hardware.  Software  for  report 
generation,  alarm  reporting,  and  other  central  operator  workstation  functions  is 
readily  available  for  industrial  controls  and  in  many  aspects  is  far  superior  to  that 
of  commercial  controls. 

The  industrial-based  personal  computer  platforms  of  the  STD  and  VME  bus 
systems  are  arguably  the  most  open  systems  of  all.  They  are  also  one  of  the  more 
expensive  alternatives  better  suited  for  high  performance  requirements  than  for 
commercial  controls.  Off-the-shelf  application  software  such  as  energy  management 
does  not  yet  exist. 

Commercial  DDC  is  currently  the  most  widely  used  type  of  controls  in  utility 
systems  at  Army  installations.  The  off-the-shelf  application  programs  for  energy 
management  are  an  asset  that  other  alternatives  cannot  yet  offer,  although  this  is 
expected  to  change  soon.  Because  commercial  DDC  was  developed  specifically  for 
utility  controls  (HVAC  in  particular),  those  vendors  routinely  have  on  staff 
personnel  that  understand  the  process  to  be  controlled  slightly  better  than  other 
industries.  BACnet  has  the  potential  to  significantly  affect  the  commercial  controls 
industry.  While  it  is  expected  that  it  will  be  many  years  before  that  potential 
impact  is  realized  to  its  full  potential,  it  is  off  to  a  good  start.  Eleven  vendors 
demonstrated  BACnet  compliant  interoperable  products  at  the  primary  network 
interface  and  operator  workstation  levels  (conformance  classes  3  and  6)  at  the 
February  1996  ASHRAE  winter  meeting. 


Recommendations 

Because  the  controls  industry  is  changing  so  rapidly,  it  is  tempting  to  recommend 
a  “wait  and  see”  approach.  Unfortunately  one  never  knows  how  long  the  wait  will 
be.  Eight  years  ago  it  was  easy  to  say  that  the  Army  should  wait  until  the  BACnet 
standard  is  developed  and  widely  implemented  by  industry.  Yet  even  today  nobody 
knows  how  much  longer  this  wait  will  be.  The  single-loop  panels  were  adopted  as 
an  interim  measure  to  fill  in  the  gap  between  then  and  the  still  awaited  adoption 
of  BACnet  or  its  equivalent.  Of  the  other  hardware  investigated,  PLCs  are  the  most 
applicable  for  Army  utilities.  They  are  cost  effective,  reliable,  easily  maintained 
and  operated,  have  an  adopted  programming  standard,  and  are  at  least  as  close  to 
a  standard  communications  protocol  as  commercial  DDC. 

However  PLCs,  like  all  controls,  have  their  drawbacks,  it  is  anticipated  that  a 
industry  will  eventually  adopt  standard,  non-proprietary  communications  protocol 
such  as  BACnet,  which  will  result  in  an  increase  in  the  use  of  DDC.  While  a 
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corresponding  decrease  in  the  use  of  commercial  SLDC  is  also  anticipated,  certain 
applications  will  continue  to  be  uniquely  suited  to  SLDC,  and  will  likely  continue 
to  use  those  controls. 
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Engr  Societies  Library 
ATTN:  Acquisitions  10017 

Defense  Logistics  Agency 
ATTN:  MMDIS  22060-6221 

Walter  Reed  Army  Medical  Ctr  20307 

National  Guard  Bureau  20310 
ATTN:  NGB-ARI 

US  Military  Academy  1 0996 
ATTN:  MAEN-A 
ATTN:  Facilities  Engineer 
ATTN:  Geography  &  Envr  Engrg 


TRADOC 
Fort  Monroe  23651 
ATTN:  ATBO-G 
Installations:  (20) 

Fort  Belvoir  22060 
ATTN:  CETEC-IM-T 
ATTN:  CETEC-ES  22315-3803 
ATTN:  Water  Resources  Support  Ctr 


Naval  Facilities  Engr  Command 
ATTN:  Facilities  Engr  Command  (8) 

ATTN:  Division  Offices  (11) 

ATTN:  Public  Works  Center  (8) 

ATTN:  Naval  Constr  Battalion  Ctr  93043 

ATTN:  Naval  Facilities  Engr  Service  Center  93043-4328 

416th  Engineer  Command  60623 
ATTN:  Gibson  USAR  Ctr 


US  Army  HSC 
Fort  Sam  Houston  78234 
ATTN:  HSLO-F 
Fitzsimons  Army  Medical  Ctr 
ATTN:  HSHG-DPW  80045 

Tyndall  AFB  32403 
ATTN:  HQAFCESA  Program  Ofc 
ATTN:  Engrg  &  Srvc  Lab 

Randolf  AFB  78150-4321 
ATTN:  HQ  AETC/CEOE 

USA  TSARCOM  63120 
ATTN:  STSAS-F 

American  Public  Works  Assoc.  64104-1806 

US  Army  CHPPM 
ATTN:  MCHB-DE  21010 

US  Gov’t  Printing  Office  20401 
ATTN:  Rec  Sec/Deposit  Sec  (2) 

Nat’l  Institute  of  Standards  &  Tech 
ATTN:  Library  20899 

Defense  General  Supply  Center 
ATTN:  DGSC-WI  23297-5000 

Defense  Construction  Supply  Center 
ATTN:  DCSC-WI  43216-5000 

US  Navy  NCEL  CODW  L72 
ATTN:  NFESC  Code  21 

Defense  Tech  Info  Center  22060-6218 
ATTN:  DTIC-0  (2) 
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